home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 4 / Apprentice-Release4.iso / Languages / Rewrite 0.2.6 / ReWrite 0.2.6 Docs / ReWrite 0.2.6 Docs.rsrc / TEXT_140.txt < prev    next >
Encoding:
Text File  |  1995-08-23  |  9.0 KB  |  170 lines

  1.  
  2. Appendix 4 - Implementation
  3.  
  4. This section details some of the inner workings of ReWrite. Knowledge of this is not required to use ReWrite, but it gives some idea of why things are set up the way they are, and how ReWrite compares to other languages. It also discusses some aspects of efficiency (see next section).
  5.  
  6. Note: this section only applies to ReWrite 0.2.x - it may not be relied on for future versions because they may be different. Also, some of this has been somewhat simplified.
  7.  
  8. Storage
  9.  
  10. Everything in ReWrite is stored in cells.  A cell has the following structure:
  11.  
  12.  
  13.  
  14.  
  15.  
  16. where type is
  17.         0 - data is a pointer to a list,
  18.         1 - data is a 32 bit integer,
  19.         2,3  are unused,
  20.         4 - data is a boolean,
  21.         5 - data is  null  (no data),
  22.         6 - data is a character,
  23.         7 - data is a token.
  24.  
  25. An integer is stored the following way:
  26.  ¬†
  27.  
  28.  
  29.  
  30. A list is stored in the following way:
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.    Since the first and last elements of the list are both stored, concatenation of lists becomes easy, as the last element does not need to be searched for. For example, appending to a list (typically a slow operation in Lisp) is just as quick as prepend.
  42.  
  43.     The cells are all stored in freelists, so a lot of memory management complications don't arise.
  44.  
  45.    Another feature of ReWrite is that of unique references - all data structures are stored strictly as trees; i.e. more than one pointer to the same structure is not allowed. This has several major consequences:
  46.  
  47. ‚Ä¢  List surgery becomes completely safe, since no other structures will be interfered with. In ReWrite, all list operations are done surgically;
  48.  
  49. ‚Ä¢  The code can keep track of what values are in use, since if a particular function has no further need of a value, it can safely dispose of it. All functions in fact keep track of this, and any value is disposed of as soon as it is no longer required (see below). As a result, there is no need to perform any garbage collection.
  50.  
  51. ‚Ä¢  The disadvantage is that much more copying of structures needs to be done than would otherwise be necessary, and this can seriously impair performance. (Also see the section on coding efficiency).
  52.  
  53.    An example of this last point is the following function that prepends the size of a list onto a list (for example for conversion to a Pascal string):
  54.  
  55. pstring[x:lis] -> {length[x],.x};
  56.  
  57. The list x needs to be copied and passed to the length function,  which counts the elements of x then destroys the list again. This turns what could otherwise be a quick function into something much less efficient.
  58.  
  59. Evaluation
  60.  
  61.    There are several steps taken in function evaluation. Presented here is a simplified idea of what happens. In the interests of simplification, all of the optimisation that is done has been omitted. For example, in practice operations like arithmetic functions are all done inline wherever possible to save the overhead of list construction and a function call.
  62.  
  63. ‚Ä¢  The following is set up at the before a function is called:
  64.    -   all the arguments to the function are in a list to be passed to the function
  65.            (which we will call arglist);
  66.    -   there is a list (which we will call resultlist) to which the result of the
  67.            function call will be appended.
  68.  
  69. ‚Ä¢  When the function is called, there is a check for:
  70.    -   whether the free stack space is running low;
  71.    -   whether the user has told the program to abort.
  72. If either of these conditions are met, then the program is aborted.
  73.  
  74. ‚Ä¢  The argument list is matched with the parameter list for the function (including any necessary condition checks). Although it is easiest when looking at how code works to imagine it done on a rule by rule basis, ReWrite may do checks that apply to several rules - it remembers what checks have succeeded and failed previously and never repeats them.
  75.    In the following example (which will be used throughout this section), the second and third rules have only the condition separating their left hand sides, so if the match for the second rule fails only on the condition, the match for the third rule will automatically succeed.
  76.  
  77. primex[lis,s,0,k:int] -> k-1;
  78. primex[lis,s,n:int,k:int]::k>s*s -> primex[lis,s+1,n,k];
  79. primex[lis,s,n:int,k:int] -> primex2[primetest[s,k,{},.lis],s,n,k];
  80.  
  81. The pseudo-code for the match for this is something like (where expr.n  refers to the n th element of the expr - this notation is not supported in ReWrite):
  82.  
  83. if arglist.1 exists then
  84.   if arglist.2 exists then
  85.     if arglist.3 exists is an integer then
  86.       if arglist.4 exists is an integer then
  87.         if arglist.3 = 0 then
  88.           do right hand side of rule 1;
  89.         else
  90.           if arglist.4 > arglist.2 * arglist.2 then
  91.             do right hand side of rule 2;
  92.           else
  93.             do right hand side of rule 3;
  94.       else
  95.         fail;
  96.     else
  97.       fail;
  98.   else
  99.     fail;
  100. else
  101.   fail;
  102.  
  103.    The mechanism used for checking conditions is similar to that used for evaluating the right hand side with one exception - all arguments are copied, instead of just the duplicates (see below).
  104.  
  105.    It is important to note that while doing the matching and condition checking, arglist is not tampered with at all. This is because if the match fails, arglist may be needed somewhere else - either as part of an error report, or there may be another version of the function later down the execution chain that can be tried.
  106.  
  107. ‚Ä¢  Once a successful match has been found (i.e. execution is now committed to a particular rule), any parts of arglist that will not be needed are destroyed. From the example above:
  108.  
  109. primex[lis,s,0,k:int] -> k-1;
  110. lis,s,0 and the list structure surrounding  arglist are destroyed.
  111.  
  112. primex[lis,s,n:int,k:int]::k>s*s -> primex[lis,s+1,n,k];
  113. Only the list structure surrounding  arglist is destroyed.
  114.  
  115. primex[lis,s,n:int,k:int] -> primex2[primetest[s,k,{},.lis],s,n,k];
  116. Only the list structure surrounding  arglist is destroyed.
  117.  
  118. ‚Ä¢  Execution of the right hand side is done in the following way:
  119.  
  120.   *  If an argument is found, one of two things happen:
  121.     -  If this is the last use of the argument, it is appended onto the resultlist;
  122.     -  If this is not the last use, then a copy of the argument is appended onto resultlist.
  123.  
  124.   *  If a function call is found, the following sequence is done:
  125.     -  resultlist is saved somewhere (on the machine stack);
  126.     -  resultlist is set to {};
  127.     -  the arguments of the function are executed in the normal way;
  128.     -  resultlist is put into arglist, and the old resultlist restored;
  129.     -  the function is called (or if it at the top level of the rhs, jumped to).
  130.  
  131. This method of evaluating the rhs has the effect that a function can return any number of results - they are all just appended to resultlist. Also note that tail recursion is supported (in fact required - an early version that had a bug and didn't do tail recursion properly required a 2 megabyte stack).
  132.  
  133. In the above example,
  134.  
  135. primex[lis,s,0,k:int] -> k-1;
  136.  
  137. - resultlist is saved;
  138. - resultlist is set to {};
  139. - k and 1 are appended to resultlist, resultlist is put into arglist, and the old resultlist restored;
  140. - the function minus is jumped to with arglist = {k,1}, thus having used no space on the stack.
  141.  
  142. primex[lis,s,n:int,k:int] -> primex2[primetest[s,k,{},.lis],s,n,k];
  143.  
  144. - resultlist is saved and set to {};
  145. - resultlist is saved and set to {};
  146. - a copy of s and a copy of k are appended to resultlist,
  147. - {} is appended to arglist (actually another function call, but compressed for clarity);
  148. - each of the elements of lis is appended to resultlist (technically another function call, but this is optimised out);
  149. resultlist is put into arglist, and the old resultlist restored;
  150. - the function primetest is called;
  151. - s, n and k are appended to resultlist;
  152. resultlist is put into arglist, and the old resultlist restored;
  153. -  primex2 is jumped to.
  154.  
  155. Compiling
  156.  
  157.    The above describes the method used to evaluate rules. There are several steps required to turn it into machine code:
  158.  
  159. ‚Ä¢  Internal macro's (all those things beginning with AsmM  in the rulelist) are used to expand something like the pseudo-code given above into a lump of intermediate code, which is sort of like a low level C or a high level assembly code program. This does not have any data structures, but is high enough level to be (mostly) machine independent. This intermediate code can be coded directly, but is unstable in its current version and is therefore undocumented. It may be documented in ReWrite 0.3.
  160.    The intermediate code is designed to be easy to port, and all the low level routines are written directly in this. ReWrite itself contains no direct machine code (although there is some glue code to connect it to the Pascal interface);
  161.  
  162. ‚Ä¢  The intermediate code then goes through a register folder which assigns a register of the 680x0 to each of the variables in the code;
  163.  
  164. ‚Ä¢  The resulting code is then converted to instructions for the 680x0;
  165.  
  166. ‚Ä¢  The resulting code is saved to disk with the prefix l.name ;
  167.  
  168. ‚Ä¢  The last task is to link all the function calls up with the functions. This is done over the whole code when everything has been compiled.
  169.  
  170.